Remarks 

Applicant respectfully requests reconsideration and allowance of the 
subject application. Claims 1, 2, 7, 11, and 33-54 are amended. Claims 1-13 and 
33-56 are pending. 

Double Patenting 

Applicant respectfully requests that the double patenting rejection be held 
in abeyance until the other rejections are withdrawn at which time, if still 
applicable, it will be addressed. 

Specification and §101 Rejection 

The specification was objected to for support of "one or more computer 
readable tangible media". See Office Action, Page 4. Additionally, claims 33-43 
were rejected under 35 U.S.C. §101 because the Examiner asserted that the 
Applicant's specification does not limit the embodiments of a computer readable 
medium. It is respectfully submitted that this is not the standard for §101. 
Regardless, support for an "article of manufacture" as currently amended may be 
found throughout the specification and drawings as filed. For example, paragraph 
[0057] of the specification recites that "a personal computer (PC) can take on the 
role of a client or server (or central server) or even both client and server" and thus 
inherently provides support as a personal computer includes an article of 
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manufacture that includes bus is not limited to a signal bearing medium. 
Withdrawal of the objection and the rejection is respectfully requested. 

§112 Rejection 

Claims 7 and 39 have been amended to correct the dependency "said 
plurality of contact information." Withdrawal of the rejection is respectfully 
requested. 

§§102 and 103 Rejections 

Claims 1, 2, 4-13, 33, 34, 36-45, and 47-56 are rejected under 35 U.S.C. 
§ 102(e) as being anticipated by U.S. Patent No. 6,584,564 to Olkin et al 
(hereinafter "Olkin"). Claims 3, 35, and 46 are rejected under 35 U.S.C. §103 as 
being obvious over Olkin. The Applicant respectfully disagrees and reserves the 
right to challenge the use of Olkin as a reference at a later time. 

The Examiner asserts in the Office Action dated December 23, 2008 
(hereinafter "Office Action") that "if said first user will accept said 
communication, establishing a direct link between said first client machine and 
said second client machine to deliver said communication in which said direct 
link: if established is configured such that said communication is not delivered 
through said discovery machine; and is not established if said first user will not 
accept said communication (fig. 1, reference no. 38 and 40)." 
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However, Olkin states the following with respect to the asserted reference 
numbers. 

In a stage 38 the sending unit 18 sends the now encrypted 
secure e-mail 14. This can be essentially transparent or 
seamless to the sender 12, being handled in the software 
module 26 of the sending unit 18 by passing the now 
encrypted secure e-mail 14 to a conventional e-mail type 
application and automatically providing a suitable "Send" 
command. The secure e-mail 14 then proceeds in 
conventional manner to the e-mail server 22, arriving in the 
inbox of each of the target receivers 16. Notably, the body of 
the secure e-mail 14 is encrypted during the entire time that it 
is passing between the sending unit 1 8 and the receiving units 
20. Optionally, the subject may also be encrypted during this 
time. 

In a stage 40 the secure e-mail 14 arrives in the inbox of each 
receiver 16. When a receiver 16 opens the secure e-mail 14, 
using their receiving unit 20, the software module 26 for the 
receiving unit 20 detects that the secure e-mail 14 is 
encrypted. Depending upon its configuration, the software 
module 26 can then prompt the receiver 16 for a password or 
use one already known to it. See Olkin, Col. 6, line to Col. 7, 
Line 14. 
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Thus, as shown above Olkin (in the above excerpt and elsewhere) merely 
describes delivery of an encrypted email. However, claim 1 as amended recites in 
part "if said first user will accept said communication, establishing a direct link 
between said first client machine and said second client machine to deliver said 
communication in which said direct link ... and wherein no direct link is 
established if said first user will not accept said communication" which is not 
disclosed by Olkin. Rather, Olkin describes delivery of an encrypted secure e- 
mail that "proceeds in a convention manner to the e-mail server 22, arriving in the 
inbox of each of the target receivers 16" regardless of whether a user will accept 
the message. 

Claims 2-13 depend either directly or indirectly from claim 1 and are 
allowable as depending from an allowable base claim. Each of the dependent 
claims is allowable based at least on the same rationale discussed with respect to 
claim 1. These claims are also allowable for their own recited features which, in 
combination with those recited in claim 1 , are neither shown nor suggested in the 
references of record, either singly or in combination with one another. 
Withdrawal of the rejections is respectfully requested. 

For example, Claim 4 recites "wherein a new direct link is established 
between said second client machine and said first client machine to communicate a 
new communication." However, the Examiner asserts that "each successive 
communication requires a new link." See Office Action, Page 7. This is not true 
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and the Applicant respectfully requests that the Examiner provide support for this 
statement or withdraw the rejection. 

In another example, Claim 11 recites "wherein a one-directional 
communication link is established to said third user when at least one of said first 
and said second user replies to said new communication and wherein said one- 
directional communication link allows said third user to send a future 
communication directly to said first or second user." In rejecting this claim, the 
Examiner asserts "(fig. 1, sender and receiver; 10:4-10, a message can be sent 
either securely [i.e. via the security server] or by conventional means)." See Office 
Action, Page 8. The asserted portion of Olkin does not describe a link nor direct 
communication. Accordingly, the Applicant respectfully requests that the 
Examiner provide support for this assertion or withdraw the rejection. 

Regarding Claims 33, 34-43, 44, and 45-56 the Examiner asserted that 
these claims are rejected for the same reasons set forth in the rejections of claims 
1, 2, and 4-13. Although the Applicant respectfully disagrees, the Applicant will 
not further burden the record as these claims are allowable for based on similar 
reasoning to that described above, as well as for other reasons. Withdrawal of the 
rejection is respectfully requested. 

35 U.S.C. S 103(a) Rejection 

Claims 1-4, 6-8, 13, 33-36, 38-40, 44-47, 49-51, and 56 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 5,054,019 to 
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Mathis et al. (hereinafter "Mathis") in view of U.S. Patent No. 6,941,148 to 



Hansmann et al. (hereinafter "Hansmann"). The Applicant respectfully traverses 

the rejection and reserves the right to challenge use of the asserted references by 

the Examiner at a later time, such as to antedate the references. 

In rejecting claim 1, the Examiner first asserts Mathis. However, Mathis 

merely describes a first node and a second node, and does not teach or suggest a 

third device such as the discovery machine as recited in Claim 1 . Because of the 

lack of teaching or suggestion of a third device, Mathis is merely relied upon to 

support communication between a first and second node: 

In some situations, it is necessary for a local node to be able 
to transmit data to and receive data from a remote node in a 
single transaction. This prevents interference from third party 
nodes during the time between closing of a transmission link 
in one direction and initiating a new link in the other 
direction. See Mathis, Col. 1, Line 51-55. 

Thus, the expressed purpose of Mathis is to provide for communication between 

two devices in a single atomic link that does not involve any other devices. 

Accordingly, Mathis cannot be said to teach or suggest a system having more than 

two devices or be utilized in combination with another such reference as such a 

modification would destroy the intent of Mathis. 

The Examiner then correctly asserts the following: 

Mathis does not disclose the first user and the second user 
registering with a discovery machine, wherein the discovery 
machine is coupled to the network; wherein the 
communication is initiated via the discovery machine; the 
discovery machine determining that the first user will accept 
the communication; the discover machine establishing a 
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direct link between the first client machine and the second 
client machine; wherein at least one of the first user and the 
second user maintains a plurality of contact information; 
wherein an individual entry in the plurality of contact 
information is automatically updated when an associated user 
of the individual entry updates a corresponding entry locally 
at a client machine of the associated user; wherein a third user 
can initiate a new communication to at least one of the first 
and the second user via a web page interface coupled to the 
discovery machine; wherein the discover machine is a central 
server. See Office Action, Pages 11-12. 

To correct these defects, the Examiner now offers the following assertions 

to support a rejection using Hansmann as follows: 

Hansmann discloses a network comprising mobile devices 
(the second client machine), a DRS (the discovery machine) 
and a number of backend systems (the first device) on a 
TCP/IP network; the DRS incorporates a list of backend 
systems by which a registered user device can connect to a 
backend system. Col. 2:40-55 and lines 65-67; fig. 3. When a 
mobile device sends a request to the DRS to access a backend 
system, the DRS connects to the backend system defined by 
the selected application. Col. 5, line 42-col. 6, line 46; Fig. 2 
and 3. Hansmann further discloses an embodiment where 
after the initial connection is made by the DRS, a direct link 
is then established between the client and the backend system. 
Col. 3, lines 24-38. 

The following excerpt is taken from one of the portions of Hansmann that is 
referenced to support the rejection: 

Behind a specific WAP phone item the URL of a travel 
agency's device registry server is stored. On a double click of 
this item, step 303, the PVD connects to the DRS, step 305. 
In a first message the device ID and an application ID as well 
as a download-desired flag is transmitted to the DRS. Thus, in 
a step 310 the DRS can identify the calling device and can 
check if said device is supported, which leads to a decision 
315. 
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If it is not supported the server issues back a "not-supported" 
message, step 320 and disconnects the communication line, 
step 325 whereby the desired business process must be 
finished unsuccessfully, step 330. See Hansmann, Col. 5, 
Lines 54-65. 

As shown above, the Examiner asserts the mobile device of Hansmann as a second 
client machine, the DRS as the discovery machine, and the backend system as the 
first device. In the above excerpt, Hansmann relies on a check to see "if said 
device is supported" and thus following the Examiner's assertions it is the backend 
system of Hansmann that should be checked to see if the device is supported. 
However, as shown in the above excerpt it is the calling device (i.e., the mobile 
device) that is actually checked in Hansmann. For example, as stated in 
Hansmann "in a step 3 10 the DRS can identify the calling device and can check if 
said device is supported, which leads to a decision 315." See Hansmann, Col. 5, 
Lines 58-60. Thus, it is respectfully submitted that the assertion made by the 
Examiner is inconsistent as to which actors perform which actions and thus does 
not support a rejection of the claims. For example, the Examiner's assertion 
requires that the mobile device of Hansmann that requests the applications also be 
checked to determine whether the mobile device support the application." Mathis 
does not correct this defect, alone or in combination with Hansmann. 

Regardless, it is also respectfully submitted that the Examiner has not 
provided support for teaching or suggestion of "determining by said discovery 
machine whether a first user associated with a first client machine will accept a 
communication initiated by a second user associated with a second client 
machine" as recited by claim 1. Rather, as shown above the Examiner asserts 
"device support" in Hansmann. Therefore, in Hansmann the application is 
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communicated regardless of whether a user will accept the application if the 
application is supported by the mobile device. Mathis does not correct this defect, 
alone or in combination. Therefore, it is respectfully submitted that a prima facie 
case of obviousness has not been established and withdrawal of the rejection is 
respectfully requested. 

Claims 2, 4, 6-8 and 13 depend either directly or indirectly from claim 1 
and are allowable as depending from an allowable base claim. Each of the 
dependent claims is allowable based at least on the same rationale discussed with 
respect to claim 1 . These claims are also allowable for their own recited features 
which, in combination with those recited in claim 1, are neither shown nor 
suggested in the references of record, either singly or in combination with one 
another. 

For example, claim 3 recites, "The method as recited in claim 1 , wherein if 
said first user is not available to receive said communication, said communication 
is stored by said discovery machine until said first user becomes available". In 
rejecting claim 3, the Examiner asserts that in addition to claim 3 being 
unpatentable over Mathis in view of Hansmann, Hansmann also: 

...discloses that the registry server establishes a connection to 
the backend system through its backend router, wherein the 
router holds tables which define on which backend system the 
required application is installed. It is further notoriously well 
known in the art for routers to implement queuing disciplines; 
for example in the event that a destination is not available, a 
router implementing a fair queuing technique will queue the 
flow directed to a nonresponsive destination. Official notice 
of this teaching is taken. See Office Action, Page 10. 
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The cited portion of Hansmann is, "Then, the Registry Server establishes a 
connection to the backend system via its backend router. The router holds tables 
that define on which backend system the required application is installed." See 
Hansmann, Col. 3, Lines 38-43. Hansmann merely describes the storage of data 
and tables, and not actual communication that has yet to be delivered. In essence, 
the storage of data and tables in Hansmann is described as a kind of map for 
finding installed applications. Additionally, as stated above this communication is 
prefaced on support of the application, not acceptance of the application by a user. 
Withdrawal of the rejection is respectfully requested. 

Regarding Claims 33, 34-43, 44, and 45-56 the Examiner asserted that 
these claims are rejected for the same reasons set forth in the rejections of claims 
1, 2, and 4-13. The Applicant respectfully disagrees. However, these claims are 
allowable for based on similar reasoning to that described above, as well as for 
other reasons. Withdrawal of the rejection is respectfully requested. 

Respectfully Submitted, 

Dated: April 23, 2009 By: /William J. Breen, III/ 

William J. Breen, III 
Reg. No. 45,313 
509.755.7253 
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